ソフトウェアアーキテクチャ・ハードパーツ (O'Reilly Japan)
https://www.oreilly.co.jp/books/images/picture_large978-4-8144-0006-5.jpeg#.png
ソフトウェアアーキテクチャに絶対的な正解は存在しません。むしろ、さまざまな妥協点の中から選択を強いる難題、すなわち「ハードパーツ」が多く存在します。そのため、ソフトウェアアーキテクトには常にトレードオフを見極め、状況に合った選択をすることが求められます。本書は、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。 本書では、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった現代のソフトウェアアーキテクチャの難題と、それに対するさまざまなアプローチやパターンを紹介します。そして意思決定を難しくするトレードオフについて、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して詳しく説明します。
『ソフトウェアアーキテクチャの基礎』の著者らによる現代的なトレードオフ分析とその実践を学べる本書は、現代のソフトウェアアーキテクチャに関わるソフトウェア開発者にとって必携の一冊です。
レガシーなモノリシックシステムをリアーキテクトし現代的なアーキテクチャに改善していく総合的な過程を学べる本
議論のために具体的な状況を設定して、その状況におかれた人々の物語をベースとして進む
本書では状況とその物語をサーガと読んでいる
Sysops Squadというレガシーシステムのリアーキテクチャに迫られた人の物語が中心になってすすむ(Sysops Squadサーガ)
サーガの対話篇があって、そこで議論すべきことが一般的な技術書のような教科書的文体で展開されて...を繰り返す
avashe.iconデータをトランザクション境界をまたいで共有する方法のうち、本書内でポジティブな評価だったのでメモ
あるデータストアを読みたいノードが、そのデータに直接アクセスするのではなく、そのレプリケーションを保持してそれを読むという仕組み
キャッシュとして使う以上アトミックは望めず、結果整合性になる
レプリケーションを各ノードが確保しているので、メモリを圧迫する代わりにネットワーク障害への耐性がある
リードがほとんどのシステムに配る分には高いパフォーマンスが見込める
実現方法としてはミドルウェアで実装するしかない、hazelcastやapache igniteで実例を見られる
データ分析
pp. 384
アーキテクトたちは、データウェアハウスパターンを用いて、クエリ可能な分析データを提供するという初期の試みを行った。そこで解決が図られた基本的な問題は、業務データと分析データの分離の核心に迫るもので、一方のフォーマットやスキーマが必ずしも他方に適合しない（あるいは使用できない）というものだった。 主なデータ分析の手法としてディメンショナルモデリングがあり、DBを使った実装方法としてスタースキーマがある。基本的に業務システムからデータを抽出し、スタースキーマに変換してデータウェアハウスに保存する。 pp. 387
結局のところ、ほとんどのデータウェアハウスが失敗したのは、ウェアハウスの作成と維持に必要な労力に見合ったビジネス価値を提供できなかったからだ。このパターンは、クラウド環境が登場するずっと前からよく見られたもので、インフラへの物理的な投資に加えて、継続的な開発とメンテナンスも膨大なものだった。また、データの利用者からは、ウェアハウスでは提供できない特定の種類のレポートを求められることも少なくなかった。
大規模かつ複雑な仕組みが必要で、しかも業務システムからデータを輸出し変換する仕組みが業務システムのスキーマと密結合してしまうのでつらい
「変換してロード」方式のデータウェアハウスを反転させ、「ロードして変換」する
つまり業務システムのデータをあまり変更しない形でデータレイクへレプリケートし、分析者が変換を行う
生のデータを持ってくるので運用者への追加の負荷が少なく、分析者としても機械学習の相性が良くてうれしい
データウェアハウスから色々改善されているが根本的な問題は解決しておらず、パイプラインの下層に押し付けただけ
プライバシーに関わるデータのクレンジングなどを含め、依然変換は必要
avashe.icon感想と読書メモ（随時分解予定）
ソフトウェアアーキテクチャの法則といったコアコンセプトの説明から始まり、リアーキテクトの利点を言語化し関係者を説得するステップやアーキテクチャ統制、ADRなどの組織化していくプロセス、本題である漸進的なアーキテクチャの改修など、リアーキテクトのための包括的な議論が展開される数少ない書籍で、プログラマなら必読すべき名著だと思う 個別の技術要素は幾らでもググればいい。重要なのはどういう目的や方向性をもってそれら要素を位置づけるか、という総合的な議論。この本はそれを試みた数少ない書籍といえる。
書籍のページには冒頭に公式の紹介文を引用しているのだが、はっきり言って損していると思う。内容を端的に伝えられてない。
続編ではあるのだが、今作から読み始めるのをむしろ推奨したい
本作は物語を読みながらリアーキテクトの包括的なプロセスについて学ぶ本なので、つまみ食いスタイルではなく前から読み通すのがよい
前作は辞書的な本なので、むしろ本作を読んで分からなかったところを辞書的につまみ食いする読み方でいい
pp.58 3.1.5 可用性・耐障害性
ドメインレベルおよび機能レベルの耐障害性を実現するには、アーキテクチャのモジュール化に加え非同期的通信が不可欠
システムを複数のデプロイメントユニットに分割すれば障害をそのデプロイメントユニットに隔離し、残りのシステムを正常に保てる。ただしもし他のサービスとの同期的な依存を持っていると、この隔離はできず、連鎖的に障害扱いになってしまう。分散システムで耐障害性を向上させるためには、アーキテクチャレベルでのモジュール化に加え、サービス間の非同期通信が不可欠となる。